Концептуальное и логическое проектирование базы данных

Концептуальное проектирование базы данных. Процесс создания модели используемой на предприятии информации, не зависящей от любых физических аспектов ее представления.

Первая фаза процесса проектирования базы данных называется концептуальным проектированием базы данных. Она заключается в создании концептуальной модели данных для анализируемой части предприятия. Эта модель данных создается на основе информации, записанной в спецификациях требований пользователей. Концептуальное проектирование базы данных абсолютно не зависит от таких подробностей ее реализации, как тип выбранной целевой СУБД, набор создаваемых прикладных программ, используемые языки программирования, тип выбранной вычислительной платформы, а также от любых других особенностей физической реализации. При разработке концептуальная модель данных постоянно подвергается тестированию и проверке на соответствие требованиям пользователей. Созданная концептуальная модель данных предприятия является источником информации для фазы логического проектирования базы данных.

Логическое проектирование базы данных. Процесс создания модели используемой на предприятии информации с учетом выбранной модели организации данных, но независимой от типа целевой СУБД и других физических аспектов реализации.

Вторая фаза проектирования базы данных называется логическим проектированием базы данных. Ее цель состоит в создании логической модели данных для исследуемой части предприятия. Концептуальная модель данных, созданная на предыдущем этапе, уточняется и преобразуется в логическую модель данных. Логическая модель данных учитывает особенности выбранной модели организации данных в целевой СУБД (например, реляционная или сетевая модель).

Если концептуальная модель данных не зависит от любых физических аспектов реализации, то логическая модель данных создается на основе выбранной модели организации данных целевой СУБД. Иначе говоря, на этом этапе уже должно быть известно, какая СУБД будет использоваться в качестве целевой — реляционная, сетевая, иерархическая или объектно-ориентированная. Однако на этом этапе игнорируются все остальные аспекты выбранной СУБД — например, любые особенности физической организации ее структур хранения данных и построения индексов.

В процессе разработки логическая модель данных постоянно тестируется и проверяется на соответствие требованиям пользователей. Для проверки корректности логической модели данных используется метод нормализации. Нормализация гарантирует, что выведенные из существующей модели данных отношения не будут обладать избыточностью данных, способной вызвать аномалии обновления после их физической реализации.

Построенная логическая модель данных является источником информации для этапа физического проектирования и обеспечивает разработчика физической базы данных средствами нахождения компромиссов, необходимых для достижения поставленных целей, что очень важно для эффективного проектирования. Логическая модель данных также играет важную роль на этапе эксплуатации и сопровождения уже готовой системы. При правильно организованном сопровождении поддерживаемая в актуальном состоянии модель данных позволяет точно и наглядно представить любые вносимые в базу данных изменения, а также оценить их влияние на прикладные программы и использование данных, уже имеющихся в базе.

Концептуальное и логическое проектирование — это итеративные процессы, которые начинаются в определенный момент времени и продолжаются в виде практически бесконечного ряда уточнений и улучшений. Их следует рассматривать как некий процесс изучения. По мере углубления разработчиками понимания принципов работы предприятия и смысла используемых данных, они выражают это понимание в виде той или иной модели данных. Собранная информация, в свою очередь, может потребовать внесения определенных изменений в другие части создаваемого проекта.

Концептуальное и логическое проектирование базы данных — важнейшие факторы общего успеха разрабатываемой системы. Если созданный проект не является точным отражением методов работы и структуры предприятия, то будет очень сложно, если вообще возможно, определить все необходимые пользователям представления (внешние схемы) или организовать поддержку целостности базы данных. Кроме того, могут возникнуть трудности с физической реализацией базы данных или обеспечением приемлемой производительности системы. В то же время способность адаптации к изменениям является признаком удачно спроектированной базы данных. Следовательно, всегда имеет смысл потратить необходимые время и энергию на создание наилучшего из возможных проектов.

Логическая модель, отражающая особенности представления о функционировании предприятия одновременно многих типов пользователей, называется глобальной логической моделью данных. Существует два основных подхода к созданию глобальной логической модели данных предприятия — это централизованный подход и подход на основе интеграции представлений.

Централизованный подход. Слияние требований отдельных пользователей, выраженных в виде различных пользовательских представлений, в единый набор требований всех пользователей, который исполь­зуется для создания глобальной логической модели данных.

При использовании первого подхода, который принято называть централизованным, требования всех существующих типов пользователей в отношении различных областей применения приложения объединяются с образованием единого списка требований. Характерной особенностью этого подхода является то, что списки требований состав­ляются до создания глобальной логической модели данных. Этот подход применим только при условии, что описываемая база данных не слишком велика или сложна.

Метод интеграции представлений. Слияние отдельных локальных логических моделей данных, отражающих представления различных групп пользователей, в единую глобальную логическую модель данных.

При использовании второго подхода, который принято называть методом интеграции представлений, осуществляется слияние отдельных моделей данных, отражающих представлениях разных групп пользователей и называемых локальными логическими моделями данных, в единую глобальную логическую модель данных всего предприятия. Этот подход более управляем, поскольку вся работа предварительно разделяется на более мелкие и легко контролируемые части. Трудности обычно возникают лишь при попытках слияния локальных моделей данных, созданных разными разработчиками, которые могут использовать различные термины для одного и того же понятия или, наоборот, связывать один и тот же термин с разными понятиями.

1.5. Пример базы данных «Библиотека».

Технологический процесс: учет выдачи книг в библиотеке.

1. ЧИТАТЕЛИ

2. БИБЛИОТЕКАРИ

3. КНИГИ

4. ПАСПОРТНЫЕ ДАННЫЕ

5. ТЕЛЕФОН

6. АВТОРЫ КНИГ

7. ИНВЕНТАРНЫЕ НОМЕРА КНИГ

8. УЧЕТ ВЫДАЧИ КНИГ

9. ФОНДЫ (ТИПЫ)

10. ТИПЫ ТЕЛЕФОНОВ

1. ЧИТАТЕЛИ

1.1. Код

1.2. Фамилия

1.3. Имя

1.4. Отчество

1.5. № читательского билета

1.6. Серия паспорта 4.1. Код

1.7. № паспорта 4.1. Код

1.8. Примечание

1.9. Телефон

1.10. Место основной работы

1.11. Должность

2. БИБЛИОТЕКАРИ

2.1. Код

2.2. Табельный номер

2.3. Фамилия

2.4. Имя

2.5. Отчество

2.6. Код паспорта 4.1. Код

2.7. Должность

2.8. Домашний телефон

2.9. Примечание

3. КНИГИ

3.1. Код

3.2. Название

3.3. Автор 6.1. Код

3.4. Год издания

3.5. Тираж

3.6. УДК

3.7. Шифр

3.8. Примечание

4. ПАСПОРТНЫЕ ДАННЫЕ

4.1. Код

4.2. Серия паспорта

4.3. № паспорта

4.4. Дата рождения

4.5. Место рождения

4.6. Пол

4.7. Место выдачи паспорта

4.8. Дата выдачи паспорта

4.9. Прописка (домашний адрес)

5. ТЕЛЕФОН

5.1. Код

5.2. Код читателя

5.3. Тип телефона 10.1. Код

5.4. № телефона

6. АВТОРЫ КНИГ

6.1. Код

6.2. Фамилия

6.3. Имя

6.4. Отчество

6.5. Дата рождения

6.6. Дата смерти

6.7. Краткая биография

6.8. Примечания

7. ИНВЕНТАРНЫЕ НОМЕРА КНИГ

7.1. Код

7.2. Код книги

7.3. Код фонда

7.4. Инвентарный номер

7.5. Стоимость

8. УЧЕТ ВЫДАЧИ КНИГ

8.1. Код

8.2. Код читателя

8.3. Код библиотекаря, выдавшего книгу

8.4. Код инвентарного номера книги

8.5. Код фонда

8.6. Дата выдачи

8.7. Дата возврата

8.8. Фактическая дата возврата

8.9. Код библиотекаря, принявшего книгу

9. ТИПЫ КНИЖНЫХ ФОНДОВ

9.1. Код

9.2. Наименование типа фонда

10. ТИПЫ ТЕЛЕФОНОВ

10.1 Код

10.2 Наименование типа телефона

Создадим логическую модель базы данных, позволяющей вести учет выдачи книг в библиотеке.

Начнем с субъектов данного процесса. Сразу можем выделить три субъекта: ЧИТАТЕЛИ, БИБЛИОТЕКАРИ и КНИГИ. Начнем описание свойств этих субъектов с читателей. Свойства каждого субъекта будут являться названиями столбцов таблицы. Информация о субъектах, участвующих в процессе выдачи книг, будем заносить в строки таблицы. Итак, ЧИТАТЕЛИ.

Заглавие первой колонки во всех таблицах будет одно и тоже – «КОД». Это, как правило. Но в дальнейшем мы увидим, как и большинство правил, будет иметь исключения. Заглавие колонки в нашей таблице соответствует заглавию, или точнее, названию поля в таблице, входящей в состав базы данных. Поэтому далее мы будем говорить о полях таблицы, а не об ее колонках.

Следующие четыре поля таблицы «ЧИТАТЕЛИ» ­ «Фамилия», «Имя», «Отчество», «№ читательского билета» - вопросов не вызывают. Далее идут два поля: «Серия паспорта» и «№ паспорта». Эти два поля подразумевают, что в базе данных должны быть паспортные данные каждого читателя. Выделим для их хранения отдельную таблицу. «Паспортные данные». В поле «Примечание» поместим дополнительные данные по каждому читателю, для которых не выделены отдельные поля в таблице.

Обратим внимание на поля «Телефон». У читателя в настоящее время может быть три типа телефонов: домашний, рабочий и мобильный. Следовательно, для этой информации необходимо выделить отдельную таблицу: «Телефоны».

Рассмотрим таблицу «Паспортные данные», состоящую из таких полей: «Код», «Серия паспорта», «№ паспорта», «Дата рождения», «Место рождения», «Пол», «Место выдачи паспорта», «Дата выдачи паспорта», «Прописка (домашний адрес)». Ни одно из полей не располагает выделение под информацию в нем хранящуюся еще одной таблицы. Теперь нам осталось заменить в поле «ЧИТАТЕЛИ» поля 1.6 и 1.7 одним полем – «Код паспорта».

В этом случае у нас получится, что в строке таблицы, соответствующий одному читателю в поле код паспорта будет находится код (номер строки таблицы «Паспортные данные») соответствующий строке таблицы «Паспортные данные», в которой хранится номер и серия паспорта этого читателя с остальной информацией, выписанной из его паспорта.

Рассмотрим таблицу «Телефоны». Она содержит четыре поля: «Код», «Код читателя», «Тип телефона», «№ телефона». В поле «Код» помещается уникальный номер строки таблицы. В поле «Код читателя» помещается значение поля 1.1 таблицы «ЧИТАТЕЛИ», соответствующий строке таблицы, в которой содержится информация о хозяине телефона. Следовательно, в данной таблице поле 5.1 «Код» лишнее, т.к. мы по полю 5.2 «Код читателя» по таблице 1. «ЧИТАТЕЛИ» однозначно определяем хозяина телефона.

Таблица 10 «Тип телефона» введена исключительно для того, чтобы при просмотре базы данных названия типов телефонов были одинаковы не только для пользователей на экране, но и для запросов, обеспечивающих поиск по типам телефонов читателей. Она содержит всего два поля: «Код» и «Наименование типа телефона». В поле «Наименование типа телефона», скорее всего, будет только отмечено три типа телефонов: «домашний», «рабочий» и «мобильный». Как Вы уже догадались в таблице 5. «ТЕЛЕФОН» вместо поля 5.3 «Тип телефона» будет поле «Код типа телефона», значение в котором будут соответствовать типу телефона из таблицы 10.

На этом будем считать, что всю информацию о читателях мы сможем получить из нашей базы данных. Займемся таблицей 2. «БИБЛИОТЕКАРИ». Она будет содержать девять полей: «Код», «Табельный номер», «Фамилия», «Имя», «Отчество», «Код паспорта», «Должность», «Домашний телефон», «Примечание».

Отметим ряд особенностей данной таблицы и общие черты с таблицей «ЧИТАТЕЛИ». Во-первых, в ряде случаев «Код» работника предприятия совпадает с его «Табельным номером», который больше интересен бухгалтерии для начисления заработной платы. Тогда поле «Код» не понадобилось бы. Во вторых, как и в таблице «ЧИТАТЕЛИ» выделены под фамилию, имя и отчество отдельные поля. В принципе, под Ф.И.О. можно выделить одно поле, но опыт показывает, что если фамилия, имя и отчество людей находятся в разных полях, работать с этой информацией легче. В-третьих, паспортные данные библиотекарей хранятся в той же таблице, что и паспортные данные читателей (см. поле 2.6. «Код паспорта»). В-четвертых, обратите внимание на поле 2.7. «Должность». В реальной задаче эту информацию необходимо было бы брать из таблицы, в которой хранится штатное расписание работников библиотеки по соответствующему коду должности. В нашем случае, чтобы не усложнять задачу, мы будем вписывать в данное поле просто название должности. В-пятых, поле 2.8. «Домашний телефон» предполагает, что нас интересует только домашний телефон библиотекаря. Если мы захотим иметь более одного телефона библиотекаря, тогда необходимо несколько модифицировать таблицу «Телефоны» (например, добавить еще одно поле, которое позволило бы отличать, принадлежит ли настоящий телефон читателю, или он принадлежит работнику библиотеки) и вписывать соответствующий код в поле «Код телефона», введенного вместо поля «Домашний телефон» в таблицу «БИБЛИОТЕКАРИ».

Рассмотрим структуру таблицы 3. «КНИГИ». Она состоит из следующих полей: «Код», «Название», «Автор», «Год издания», «Тираж», «УДК», «Шифр», «Примечание». Обратим внимание на поле 3.3. «Автор». Напрашивается выделение для авторов книг отдельной таблицы «АВТОРЫ КНИГ». В этом случае поле «Автор» заменим на поле «Код автора», в котором будем прописывать номер строки таблицы «Авторы книг», содержащей информацию об авторе книги. Такое решение продиктовано тем, что одним автором могут быть написаны много книг. Поля 3.6. «УДК» и 3.7. «Шифр» можно было бы расписать так, как это делают в библиотеке по темам, в зависимости от их значений. Но не будем этого делать, тем самым упростим задачу.

Рассмотрим таблицу 6. «АВТОРЫ КНИГ». Она состоит из следующих полей: «Код», «Фамилия», «Имя», «Отчество», «Дата рождения», «Дата смерти», «Краткая биография» и «Примечание». Обратим внимание на два поля «Краткая биография» и «Примечание». Из названия поля «Краткая биография» становится понятным, что в данном поле должен храниться текст. В поле «Примечание» так же предполагается хранить текст. Эти два поля имеют один тип. Назовем их текстовыми полями.

Только теперь мы рассмотрим таблицу, в которой собственно, и ведется учет выдачи книг. Так мы ее и назвали «УЧЕТ ВЫДАЧИ КНИГ». В первом приближении данная таблица имела следующие поля: «Код», «Код читателя», «Код библиотекаря, выдавшего книгу», «Код инвентарного номера книги», «Дата выдачи», «Дата возврата», «Фактическая дата возврата», «Код библиотекаря, принявшего книгу». Однако, первое поле «Код» нам не нужно, если данная информация не будет использоваться в дальнейшем ни в одной из таблиц. Но в целях развития системы его можно оставить «Код читателя» имеет значение, соответствующее значению поля «Код» в таблице «ЧИТАТЕЛИ», из той строки, в которой содержится информация о читателе, взявшем книгу. Поле «Код книги» было заменено на «Код инвентарного номера книги». Это сделано для того, чтобы в отдельной таблице «Инвентарные номера книг» учесть количество книг, находящихся в фондах и на руках у читателей. Поле «Фактическая дата возврата» введено для того, чтобы определить добросовестных читателей и выявить тех, кто не возвращает книги в оговоренный срок.

Рассмотрим таблицу «ИНВЕНТАРНЫЕ НОМЕРА КНИГ». Она содержит четыре поля: «Код», «Код книги», «Код фонда», «Инвентарный номер», «Стоимость». Поле «Код книги» содержит номер строки из таблицы «КНИГИ», в которой прописана информация о книге, имеющей инвентарный номер (поле «Инвентарный номер») из определенного фонда библиотеки (Поле «Код фонда»). В поле «Цена» указана цена книги, которую должен возместить читатель в случае её потери.

Осталась последняя таблица «ТИПЫ КНИЖНЫХ ФОНДОВ», имеющая всего два поля: «Код» и «Наименование фонда». Например, для библиотеки ДГУ известны два фонда: «НТБ» и «Студенческий». Следовательно, если бы данная база данных создавалась для учета выдачи книг в нашей библиотеке, то в этой бы таблице было бы всего две записи:

Код Наименование типа фонда

1 НТБ

2 Студенческий.

На этом создание логической модели базы данных для учета выдачи книг библиотекой будем считать завершенной.

КОНТРОЛЬНЫЕ ВОПРОСЫ:

1. Что такое информационная система организации?

2. Какие компоненты включает в себя типичная информационная система?

3. Перечислите известные Вам этапы жизненного цикла базы данных.

4. Являются ли жизненного цикла приложения базы данных строго последовательными. Почему?

5. Что такое концептуальное проектирование базы данных?

6. Что такое логическое проектирование базы данных?

7. Чем отличается концептуальное проектирование базы данных от логического?

8. Какой метод используется для проверки логической модели данных и что он гарантирует?

9. Какие два подхода к созданию глобальной логической модели предприятия Вам известны?

10. В чем заключается централизованный подход к созданию глобальной логической модели данных предприятия, его характерная особенность?

11. В чем заключается подход к созданию глобальной логической модели данных предприятия на основе интеграции представлений, в чем его характерная особенность?

Дата добавления: 2014-01-05