Лекция №4                                                                                                

 

Лекция 4 : Основные этапы проектирования базы данных

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

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

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

3)    определение требований:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 Цель этапа концептуального проектирования - создание концептуальной модели данных исходя из представлений пользователей о предметной области. Для ее достижения выполняется ряд последовательных процедур

 

• определение сущностей и их документирование;

• определение связей между сущностями и их документирование;

• создание модели предметной области;

• определение атрибутов и их документирование;

• определение значений атрибутов и их документирование;

• определение первичных ключей для сущностей и их документирование.

 

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

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

• выбор модели данных;

• определение набора таблиц и их документирование;

• нормализация таблиц;

• определение требований поддержки целостности данных и их документирование.

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

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

• проектирование таблиц базы данных средствами выбранной СУБД;

• проектирование физической организации базы данных;

•разработка стратегии защиты базы данных.

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

 Синтез компьютерной модели объекта.

В процессе создания компьютерной модели можно выделить некоторые стадии, типичные для любой СУБД.

Стадия 1. Запуск СУБД, создание нового файла базы данных или открытие созданной ранее базы.

Стадия 2. Создание исходной таблицы или таблиц.

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

  

При проектировании таблиц, рекомендуется руководствоваться следующими основными принципами:

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

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

3. Каждая таблица должна содержать необходимые поля. Каждое поле в таблице должно содержать отдельные сведения по теме таблицы. Например, в таблице с данными о клиенте могут содержаться поля с названием компании, адресом, городом, страной и номером телефона. При разработке полей для каждой таблицы необходимо помнить, что каждое поле должно быть связано с темой таблицы. Не рекомендуется включать в таблицу данные, которые являются результатом выражения. В таблице должна присутствовать вся необходимая информация. Информацию следует разбивать на наименьшие логические единицы (Например, поля "Имя" и "Фамилия", а не общее поле "Имя").

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

Стадия 3. Создание экранных форм.

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

Стадия 4. Заполнение БД.

Процесс заполнения БД может проводиться в двух видах: в виде таблицы и в виде формы. Числовые и текстовые поля можно заполнять в виде таблицы, а поля типа МЕМО и OLE – в виде формы.

VI этап. Работа с созданной базой данных.

Работа с БД включает в себя следующие действия:

·         поиск необходимых сведений;

·         сортировка данных;

·         отбор данных;

·         вывод на печать;

·         изменение и дополнение данных.

Процесс проектирования ИС состоит из (см.рис):

·         сбора данных;

·         составления частных ЛПП;

·         унификации пересекающихся эпизодов;

·         составления ГПП;

·         формирования модели предметной области (инфологическое проектирование);

·         составления схемы с учетом используемого СУБД (концептуальное проектирование);

·         физического проектирования.

                       

Инфологическое моделирование

 

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

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

Какими же средствами воспользоваться для составления инфологического описания предметной области? На этот вопрос нет однозначного ответа. Существует несколько методик, и соответственно применяются разные инструментальные средства. Составляемая модель должна быть проста, наглядна, содержать все сведения для дальнейших этапов проектирования, легко преобразовываться в модели баз данных для распространенных СУБД. Исходя из этих требований, в описываемой методике проектирования используется модель, названная «сущность-связь» (или «объекты-связи»).

Модель «сущность-связь» позволяет представлять объекты предметной области и отношения между ними, т.е. позволяет описывать структуру предметной области. Она определяется в терминах: сущность, атрибут, связь.

Сущность - представление (абстракция) реально существующего объекта, процесса или явления. Наименование сущности должно быть уникально во всей модели.

Тип сущности - определяет набор однородных объектов.

Экземпляр сущности - конкретный объект из этого набора.

Например: сущность «Ученик» определяет всю информацию об учениках вообще. Конкретный ученик Ваня Иванов является экземпляром сущности «Ученик», а совокупность всех учеников составляет тип сущности.

Атрибут - свойство сущности (объекта). Его имя должно быть уникально в рамках одной сущности.

Экземпляр атрибута- конкретное значение свойства.

Например: сущность «Ученик» определяется атрибутами: «Фамилия ученика», «Класс» и т.п. То есть для каждого конкретного ученика (экземпляра сущности) мы должны определить экземпляры атрибутов (их конкретные значения). Продолжим с нашим примером: экземпляр сущности «Ученик» Ваня Иванов имеет экземпляр атрибута «Фамилия ученика» - «Иванов» и экземпляр атрибута «Класс» - «8А».

Идентифицирующий атрибут(идентифицирующая совокупность атрибутов, ИСА) - атрибут (несколько атрибутов), значение которого определяет уникальность экземпляра сущности.

Связьпозволяет моделировать отношения между объектами предметной области. Наименование связи должно быть уникально во всей модели.

Перечислим те правила, которым должна удовлетворять модель «сущность-связь»:

1.  Модель должна давать полное представление о предметной области.

2.  Должны быть перечислены все необходимые для реализации задачи сущности и их атрибуты соответственно.

3.  Имена сущностей должны быть уникальны.

4.  Имена атрибутов в пределах одной сущности должны быть уникальны.

5.  Мы должны гарантировать однозначную трактовку модели.

6.  В каждой сущности должна быть выделена идентифицирующая совокупность атрибутов.

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

При построении инфологических моделей можно использовать язык ER-диаграмм (от англ. Entity-Relationship, т.е. сущность-связь). В них сущности изображаются помеченными прямоугольниками, ассоциации – помеченными ромбами или шестиугольниками, атрибуты – помеченными овалами, а связи между ними – ненаправленными ребрами, над которыми может проставляться степень связи (1 или буква, заменяющая слово "много") и необходимое пояснение.

Между двумя сущностям, например, А и В возможны четыре вида связей.

Первый тип – связь ОДИН-К-ОДНОМУ (1:1): в каждый момент времени каждому представителю (экземпляру) сущности А соответствует 1 или 0 представителей сущности В:

Студент может не "заработать" стипендию, получить обычную или одну из повышенных стипендий.

Второй тип – связь ОДИН-КО-МНОГИМ (1:М): одному представителю сущности А соответствуют 0, 1 или несколько представителей сущности В.

Квартира может пустовать, в ней может жить один или несколько жильцов.

Так как между двумя сущностями возможны связи в обоих направлениях, то существует еще два типа связи МНОГИЕ-К-ОДНОМУ (М:1) и МНОГИЕ-КО-МНОГИМ (М:N).

Пример 2.1. Если связь между сущностями МУЖЧИНЫ и ЖЕНЩИНЫ называется БРАК, то существует четыре возможныхпредставления такой связи:

Характер связей между сущностями не ограничивается перечисленными. Существуют и более сложные связи:

·         множество связей между одними и теми же сущностями

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

тренарные связи

(врач может назначить несколько пациентов на несколько анализов, анализ может быть назначен несколькими врачами нескольким пациентам и пациент может быть назначен на несколько анализов несколькими врачами);

связи более высоких порядков, семантика (смысл) которых иногда очень сложна.