Жизненный цикл базы данных

Проектирование базы данных

Оглавление

3.1. Жизненный цикл базы данных. 1

3.2. Модель «сущность-связь». 3

3.3. Этапы проектирования базы данных и их процедуры.. 8

3.3.1. Процедуры концептуального проектирования. 8

3.3.2. Процедуры логического проектирования. 10

3.3.3. Процедуры физического проектирования. 12

Жизненный цикл базы данных

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

Жизненный цикл базы данных (ЖЦБД) – это процесс проектирования, реализации и поддержки базы данных. ЖЦБД состоит из семи этапов.

1. предварительное планирование;

2. проверка осуществимости;

3. определение требований;

4. концептуальное проектирование;

5. логическое проектирование;

6. физическое проектирование;

7. оценка работы и поддержка базы данных.

Опишем главные задачи каждого этапа.

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

1. Предварительное планирование базы данных – важный этап в процессе перехода от разрозненных данных к интегрированным. На этом этапе собирается информация об используемых и находящихся в процессе разработки прикладных программ и файлах, связанных с ними. Она помогает установить связи между текущими приложениями и то, как используется их информация. Кроме того, позволяет определить будущие требования к базе данных. Информация документируется в виде обобщенной концептуальной модели данных.

2. Поверка осуществимости предполагает подготовку отчетов по трем вопросам:

1) Есть ли технологии – необходимое оборудование и программное обеспечение – для реализации запланированной базы данных (технологическая осуществимость);

2) Имеются ли персонал, средства и эксперты для успешного осуществления плана создания базы данных (операционная осуществимость);

3) Окупится ли запланированная база данных (экономическая эффективность).

3. Определение требований. На этом этапе определяются:

· цели базы данных;

· информационные потребности различных структурных подразделений и их руководителей;

· требования к оборудованию;

· требования к программному обеспечению.

4. Концептуальное проектирование. На этом этапе создаются подробные модели пользовательских представлений данных предметной области. Затем они интегрируются в концептуальную модель, которая фиксирует все элементы корпоративных данных, подлежащих загрузке в базу данных. Эту модель еще называют концептуальной схемой базы данных.

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

6. Физическое проектирование. На этом этапе логическая модель расширяется характеристиками, необходимыми для определения способов физического хранения базы данных, типа устройств для хранения, методов доступа к данным базы, требуемого объема памяти, правил сопровождения базы данных и др.

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

3.2. Модель «сущность-связь»

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

Основные понятия ER – диаграммы – сущность, атрибут, связь.

Сущность – это некоторый объект реального мира, который может существовать независимо. Сущность имеет экземпляры, отличающиеся друг от друга значениями атрибутов и допускающие однозначную идентификацию. Атрибут – это свойство сущности. Например, сущность КНИГА характеризуется такими атрибутами, как автор, наименование, цена, издательство, тираж, количество страниц. Конкретные книги являются экземплярами сущности КНИГА. Они отличаются значениями указанных атрибутов и однозначно идентифицируются атрибутом «наименование». Атрибут, который уникальным образом идентифицирует экземпляры сущности, называются ключом. Может быть составной ключ, представляющий комбинацию нескольких атрибутов.

Предположим, что проектируется база данных, предназначенная для хранения информации о деятельности некоторого банка. Этот банк имеет филиалы. Филиалы управляются менеджерами. Клиенты имеют в филиалах счета разных типов – текущие, срочные, до востребования, депозитные, карточные. Филиалы обрабатывают эти счета. Описываемую предметную область назовем БАНК. В ней могут быть выделены четыре сущности: филиал, счет, клиент.

На ER – диаграмме сущность изображается прямоугольником, в котором указывается ее имя. Например,

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

В рассматриваемой предметной области БАНК можно выделить три связи.

1. МЕНЕДЖЕР – УПРАВЛЯЕТ – ФИЛИАЛ

2. ФИЛИАЛ – ОБРАБАТЫВАЕТ – СЧЕТ

3. КЛИЕНТ – ИМЕЕТ – СЧЕТ

На ER – диаграмме связь изображается ромбом. Например,

Важной характеристикой связи является тип связи (кардинальность). Рассмотрим типы связей 1-3.

Так как менеджер управляет одним филиалом, то каждый экземпляр сущности МЕНЕДЖЕР может быть связан не более чем с одним экземпляром сущности ФИЛИАИ. В этом случае связь 1 имеет тин «один-к-одному» (1: 1). На рис. 1 представлена ER – диаграмма для связи типа 1: 1.

Рисунок 1 - ER – диаграмма связи 1: 1

Так как филиал обрабатывает несколько счетов, а счет обрабатывается только одним филиалом, то каждый экземпляр сущности ФИЛИАЛ может быть связан более чем с одним экземпляром сущности СЧЕТ, а каждый экземпляр сущности СЧЕТ может быть связан не более чем с одним экземпляром сущности ФИЛИАЛ. В этом случае связь 2 имеет тип «один –ко- многим» (1: М). На рис. 2 представлена ER – диаграмма для связи типа 1: М.

Рисунок 2 - ER – диаграмма связи 1: М

Так как счет может совместно использоваться несколькими клиентами и клиент может иметь несколько счетов, то каждый экземпляр сущности СЧЕТ может быть связан с несколькими экземплярами сущности КЛИЕНТ и каждый экземпляр сущности КЛИЕНТ может быть связан с несколькими экземплярами сущности СЧЕТ. В этом случае связь 3 имеет тип «многие – ко - многим» (М: N). На рис. 3 представлена ER – диаграмма для связи типа М: N.

Рисунок 3 - ER – диаграмма связи М: N

Рассмотрим понятие класс принадлежности сущности.

Если каждый экземпляр сущности А связан с экземпляром сущности В, то класс принадлежности сущности А является обязательным. Этот факт отмечается на ER – диаграмме черным кружочком, помещенным в прямоугольник, смежным с прямоугольником сущности А.

Если не каждый экземпляр сущности А связан с экземпляром сущности В, то класс принадлежности сущности А является необязательным. Этот факт отмечается на ER – диаграмме черным кружочком, помещенным на лини связи прямоугольника сущности А.

В качестве примера на рис. 4 изображены возможные ER – диаграммы для связи М: N с учетом класса принадлежности сущности.

Рисунок 4 - ER – диаграммы связи М: N с учетом класса принадлежности сущности

На ER – диаграмме 1 класс принадлежности обеих сущностей необязательный.

На ER – диаграмме 2 класс принадлежности сущности КЛИЕНТ обязательный, а сущности СЧЕТ необязательный.

На ER – диаграмме 3 класс принадлежности сущности КЛИЕНТ необязательный, а сущности СЧЕТ обязательный.

На ER – диаграмме 4 класс принадлежности обеих сущностей обязательный.

Предположим, что в рассматриваемой предметной области БАНК класс принадлежности всех четырех сущностей является обязательным. Тогда ER-модель предметной области БАНК будет иметь вид, представленный на рисунке 5.

Каждая из четырех сущностей приведенной ER – модели может быть описана своим набором атрибутов (рис. 6).

ER – модель в совокупности с наборами атрибутов сущностей может служить примером концептуальной модели предметной области или концептуальной схемы базы данных.

В связи с наглядностью представления концептуальных схем баз данных ER – модели получили широкое распространение в CASE – средствах. Эти средства предназначены для автоматизированного проектирования реляционных баз данных.

Рисунок 5 – Пример ER – модели предметной области БАНК

Рисунок 6 – Набор атрибутов сущностей предметной области БАНК

Примечание. Ключевые атрибуты выделены жирным шрифтом.

Широко распространены CASE-системы, позволяющие выполнять ER-диаграммы в соответствии со стандартом IDEF1X. К ним относятся, в частности, Erwin, Design/IDEF, Power Designer.

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