Лекция №2 по дисциплине «Базы данных» Жизненный цикл базы данных. Основные этапы проектирования базы данных



Скачать 135.81 Kb.
Дата15.06.2015
Размер135.81 Kb.
ТипЛекция


Лекция №2 по дисциплине «Базы данных»

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

Основные этапы проектирования базы данных.

План лекции:

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

  2. Основные этапы проектирования базы данных.


Вопрос №1. Жизненный цикл базы данных.

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

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

Стадии жизненного цикла базы данных:


  • Стадия анализа – производится анализ предметной области и выявляются требования к ней. Происходит оценка актуальности разработки.

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

  • Стадия реализации – решаются задачи по разработке программного доступа к базе данных. Проводится тестирование.

  • Стадия эксплуатации и сопровождения.

Жизненный цикл базы данных состоит из следующих этапов:

1. Предварительное планирование – планирование БД, выполняемое в процессе разработки стратегического плана БД. В процессе планирования собирается следующая информация:

  • какие прикладные программы используются, и какие функции они выполняют;

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

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

Данная информация помогает определить, как используется информация приложений, определить будущие требования к системе БД.

Информация этого этапа документируется в виде обобщенной модели данных.



2. Проверка осуществимости. Здесь определяется технологическая, операционная и экономическая осуществимость плана создания БД, т. е.:

  • технологическая осуществимость – есть ли технология для реализации запланированной БД?

  • операционная осуществимость – есть ли средства и эксперты, необходимые для успешного осуществления плана создания БД?

  • экономическая целесообразность – можно ли определить выводы? Окупится ли запланированная система? Можно ли оценить издержки и выгоду?

3. Определение требований включает выбор целей БД, выяснение информационных требований к системе и требований к оборудованию и программному обеспечению. Таким образом, на данном этапе сбора данных и определения требований создаётся общая информационная модель, выражающаяся в следующих задачах:

  • Определяются цели системы путём анализа информационных потребностей. Здесь также обязательно указывается, какую именно БД следует создавать (распределённую, целостную) и какие коммуникационные средства необходимы. Выходной документ – комментарий, описывающий цели системы.

  • Определение пользовательских требований: документация в виде обобщённой информации (комментарии, отчёты, опросы, анкеты и т. д.); фиксация функций системы и определение прикладных систем, которые будут выполнять эти требования. Данные представляются в виде соответствующих документов.

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

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

4. Концептуальное проектирование – создание концептуальной схемы БД. Спецификации разрабатываются в той степени, которая необходима для перехода к реализации.

Основным выходным документом является единая инфологическая модель (или схема БД на концептуальном уровне). При разработке данной модели используются информация и функции, которые должна выполнить система, определённые на этапе сбора и определения требований к системе. На данном этапе желательно также определить: 1) правила для данных; 2) правила для процессов; 3) правила для интерфейса.



5. Реализацияпроцесс превращения концептуальной модели в функциональную БД. Он включает в себя следующие этапы.

1) Выбор и приобретение необходимой СУБД.

2) Преобразование концептуальной (инфологической) модели БД в логическую и физическую модель данных:


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

  • определяются, какие прикладные процессы необходимо реализовать в схеме данных как хранимые процедуры;

  • реализовать ограничения, предназначенные для обеспечения целостности данных и реализации правил для данных;

  • спроектировать и сгенерировать триггеры для реализации всех централизованно определённых правил для данных и правил целостности данных, которые не могут быть заданы как ограничения;

  • разработать стратегию индексирования и кластеризации; выполнить оценку размеров всех таблиц, кластеров и индексов;

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

  • разработать сетевую топологию БД и механизм бесшовного доступа к удалённым данным (реплицированная или распределённая БД).

3) Построение словаря данных, который определяет хранение определений структуры данных БД. Словарь данных также содержит информацию о полномочиях доступа, правилах защиты данных и контроля данных.

4) Заполнение базы данных.

5) Создание прикладных программ, контроль управления.

6) Обучение пользователей.



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

Таким образом, ЖЦБД включает в себя:



  • Изучение предметной области и представление соответствующей документации (1-3).

  • Построение инфологической модели (4).

  • Реализация (5).

  • Оценка работы и поддержка БД (6).

Вопрос №2. Основные этапы проектирования.

Этапы проектирования базы данных:

  • Концептуальное проектирование – происходит сбор, анализ и редактирование требований к данным. В результате создается концептуальная модель базы данных.

  • Логическое проектирование – на основе концептуальной модели создается структура данных.

  • Физическое проектирование – определение особенностей хранения данных, методов доступа.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

При разработке БД можно выделить следующие этапы работы.

I этап. Постановка задачи.

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



II этап. Анализ объекта.

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



III этап. Синтез модели.

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



IV этап. Выбор способов представления информации и программного инструментария.

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

В большинстве СУБД данные можно хранить в двух видах:


  • с использованием форм;

  • без использования форм.

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

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

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



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

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

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

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

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

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

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

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

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

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



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

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



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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

http://www.online-academy.ru/demo/access/urok1/images/1-1.jpg

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


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

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

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

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



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

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

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

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



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

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

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



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

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

Теперь попытаемся составить полную инфологическую модель задачи «Школьный журнал». Для этого перечислим те правила, которым должна удовлетворять модель «сущность-связь»:



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

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

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

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

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

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

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

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

http://www.online-academy.ru/demo/access/urok1/images/1-2.jpg

  • Сущность «Ученик» содержит все личные данные учащегося.

  • Сущность «Кабинет» содержит информацию о техническом уровне, состоянии, количестве мест.

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

  • Сущность «Оценка» содержит информацию об оценке, полученной учеником по определенному предмету, выставленную преподавателем в конкретный день.

Концептуальное проектирование


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


Похожие:

Лекция №2 по дисциплине «Базы данных» Жизненный цикл базы данных. Основные этапы проектирования базы данных iconПрограмма Реляционные базы данных. Базы данных и средства управления ими
Реляционные базы данных. Переход от модели «Вещи – отношения» к реляционной модели
Лекция №2 по дисциплине «Базы данных» Жизненный цикл базы данных. Основные этапы проектирования базы данных iconНеофициальный перевод технический комитет
Целью настоящего документа является обновление событий, касающихся базы данных genie, системы кодов упов и Базы данных сортов растений...
Лекция №2 по дисциплине «Базы данных» Жизненный цикл базы данных. Основные этапы проектирования базы данных icon10. Нормализация базы данных. Требования к 1НФ, 2НФ, 3НФ. Пояснить процесс нормализации базы данных на конкретных примерах
Ипы нормализации (normalization). Нормализация в общем виде — это процесс преобразования отношения, имеющего некоторые недостатки,...
Лекция №2 по дисциплине «Базы данных» Жизненный цикл базы данных. Основные этапы проектирования базы данных iconЛекция 1 (db l01. ppt) Введение в Автоматизированные информационные системы (аис) и Базы данных (БД). Определение бд и банков данных (БнД). Компоненты банка данных. Цели, задачи и структура курса
Примерами таких систем являются автоматизированные системы управления предприятием, банковские системы, системы резервирования и...
Лекция №2 по дисциплине «Базы данных» Жизненный цикл базы данных. Основные этапы проектирования базы данных iconВыбор базы данных и его обоснование
Как уже говорилось выше, в реляционной модели данных есть возможность определения одного атрибута или их множества в ка
Лекция №2 по дисциплине «Базы данных» Жизненный цикл базы данных. Основные этапы проектирования базы данных iconРеферат Данные, база данных, экспорт, импорт, soap сервер, soap клиент. Дипломный проект представлен в виде пояснительной записки объемом 72 страниц. Графическая часть состоит из 4 листов формата А1 четыре чертежа: «soap сервер
«soap клиент. Схема алгоритма», «Модель импорта данных. Схема взаимодействия модулей», «Модель экспорта данных. Схема взаимодействия...
Лекция №2 по дисциплине «Базы данных» Жизненный цикл базы данных. Основные этапы проектирования базы данных iconБанк тестовых заданий по темам календарного плана курса «Базы данных»

Лекция №2 по дисциплине «Базы данных» Жизненный цикл базы данных. Основные этапы проектирования базы данных iconЯ., Фарсобина В. В. База речевых фрагментов русского языка “isabase”
Статья посвящена описанию речевой базы данных русского языка, разработанной в Институте системного анализа ран при поддержке Российского...
Лекция №2 по дисциплине «Базы данных» Жизненный цикл базы данных. Основные этапы проектирования базы данных iconТехнологии разработки баз данных средствами microsoft access
Разработка физической модели данных. Прежде чем запустить access, необходимо с карандашом в руках составить обязательные характеристики...
Лекция №2 по дисциплине «Базы данных» Жизненный цикл базы данных. Основные этапы проектирования базы данных iconПрограмма курса "Базы данных"
Модель “Сущность-связь” (er-модель). Элементы модели: сущность, атрибут, связь, идентификатор. Типы связей. Степень связи. Минимальная...
Разместите кнопку на своём сайте:
docs.likenul.com


База данных защищена авторским правом ©docs.likenul.com 2015
обратиться к администрации
docs.likenul.com