Размещено на http://www.allbest.ru/

Государственное бюджетное образовательное учреждение

среднего профессионального образования

«Волгоградский экономико-технический колледж»

Кафедра «Информационных технологий»

Курсовой проект

по МДК 02.02. «Разработка и администрирование баз данных»

по теме «Банкоматы»

Выполнил: студент группы

211-ПК Терехова Ю.А.

Проверил: доцент, к. т. н.

Кислов С.Ю.

Волгоград 2014



Оглавление

1. ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ

1.1 Требования, предъявляемые к базе данных

1.2 Этапы жизненного цикла базы данных

1.3 Модель "сущность-связь"

1.4 Преобразование ER-модели в реляционную

Правило 1

Правило 2

Правило 3

Правило 4

Правило 5

Правило 6

1.5 Нормализация таблиц

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

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

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

2. Создание базы данных

Список литературы



1. ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ

1.1 Требования, предъявляемые к базе данных

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

· целостность базы данных -- требование полноты и непротиворечивости данных;

· многократное использование данных;

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

· простота обновления данных;

· уменьшение излишней избыточности данных;

· защита данных от несанкционированного доступа, искажения и уничтожения.

1.2 Этапы жизненного цикла базы данных

база данные логический проектирование

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

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

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

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

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

· окупится ли запланированная база данных );

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

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

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

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

* требования к программному обеспечению);

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

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

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

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

1.3 Модель "сущность-связь"

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

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

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

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

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

1. ДИРЕКТОР -- УПРАВЛЯЕТ -- БАНК

2. БАНК -- ОБРАБАТЫВАЕТ -- НОМЕР КАРТЫ

3. КЛИЕНТ - ИМЕЕТ - НОМЕР КАРТЫ

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

Важной характеристикой связи является тип связи (кардинальность). Так как директор управляет только одним банком, то каждый экземпляр сущности ДИРЕКТОР может быть связан не более чем с одним экземпляром сущности БАНК. В этом случае связь 1 имеет тип "один-к-одному" (1:1). На рис.1.1 представлена ER-диаграмма для связи типа 1:1.

Рис. 1.1. ER-диаграмма связи 1:1

Так как филиал обрабатывает несколько счетов, а счет обрабатывается только одним филиалом, то каждый экземпляр сущности БАНК может быть связан более чем с одним экземпляром сущности НОМЕР КАРТЫ, а каждый экземпляр сущности НОМЕР КАРТЫ может быть связан не более чем с одним экземпляром сущности БАНК. В этом случае связь 2 имеет тип "один-ко-многим" (1:М). На рис. 1.2 представлена ER-диаграмма для связи типа 1 :М.

Рис. 1.2. ER-диаграмма связи 1:М

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

Рис. 1.3. ER-диаграмма связи M:N

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

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

1

2

3

4

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

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

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

Рис. 1.5 Пример ER-модели предметной области Банк

Каждая из четырех сущностей приведенной ER-модели может быть описана своим набором атрибутов (рис. 1.6).ER-модель в совокупности с наборами атрибутов сущностей может слу-жить примером концептуальной модели предметной области или концептуальной схемы базы данных. В связи с наглядностью представления концептуальных схем баз данных .ER-модели получили широкое распространение в CASE-средствах. Эти средства предметной области БАНК.

Клиент
Номер карты
ФИО клиента
Номер счета
Банк
Код банка
Наименование банка
Директор
Адрес

Обслуживание банкомата
Кассир
Инженер
Банк
Пластиковая карта
Тип карты
Пароль
Банк
Номер карты

Рис.1.6. Наборы атрибутов сущностей предметной области БАНК.

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

1.4 Преобразование ER-модели в реляционную

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

Правило 1

Если связь типа 1:1 и класс принадлежности обеих сущностей является обязательным, то необходима только одна таблица. Первичным ключом этой таблицы может быть первичный ключ любой из двух сущностей. На ER-диаграмме связи 1:1, представленной на рис. 1.5, класс принадлежности сущностей КЛИЕНТ, ПЛАСТИКОВАЯ КАРТА является обязательным. Тогда согласно правилу 1 должна быть сгенерирована одна таблица следующей структуры:

КЛИЕНТ - ПЛАСТИКОВАЯ КАРТА

НМ	Стаж	Тип карты	Пароль	Банк

Первичным ключом этой таблицы может быть и первичный ключ сущности БАНК , ОБСЛУЖИВАНИЕ БАНКОМАТА.

Правило 2

Если связь типа 1:1 и класс принадлежности одной сущности является обязательным, а другой - необязательным, то необходимо построить таблицу для каждой сущности. Первичный ключ сущности должен быть первичным ключом соответствующей таблицы. Первичный ключ сущности, для которой класс принадлежности является необязательным, добавляется как атрибут в таблицу для сущности с обязательным классом принадлежности. Представим, что на ER-диаграмме связи 1:1, изображенной на рис. 1.5, класс принадлежности сущности ДИРЕКТОР будет обязательный, а сущности БАНК- необязательный. Тогда согласно правилу 2 должны быть сгенерированы две таблицы.

Сущность с необязательным классом принадлежности (БАНК) именуется родительской, а с обязательным (ДИРЕКТОР) -- дочерней. Первичный ключ родительской сущности , помещаемый в таблицу, представляющую дочернюю сущность, называется внешним ключом родительской сущности. Связь между указанными таблицами устанавливается путем связи первичного и внешнего ключа .

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

Правило 3

Если связь типа 1:1 и класс принадлежности обеих сущностей является необязательным, то необходимо построить три таблицы - по одной для каждой сущности и одну для связи. Первичный ключ сущности должен быть первичным ключом соответствующей таблицы. Таблица для связи среди своих атрибутов должна иметь ключи обеих сущностей. Представим, что на ER-диаграмме связи 1:1, изображенной на рис. 1.5, класс принадлежности сущностей ДИРЕКТОР, БАНК будет необязательный. Тогда согласно правилу 3 должны быть сгенерированы три таблицы. При этом осуществляется декомпозиция связи 1:1 на две связи 1:1. Итак, для связи типа 1:1 существуют три отдельных правила формирования предварительных таблиц из ER-диаграмм. Для связи типа 1:М существуют только два правила. Выбор одного из них зависит от класса принадлежности сущности на стороне М. Класс принадлежности сущности на стороне 1 не влияет на выбор.

Правило 4

Если связь типа 1:М и класс принадлежности сущности на стороне М является обязательным, то необходимо построить таблицу для каждой сущности. Первичный ключ сущности должен быть первичным ключом соответствующей таблицы. Первичный ключ сущности на стороне 1 добавляется как атрибут в таблицу для сущности на стороне М. На ER-диаграмме связи 1:М, представленной на рис. 1.5, класс принадлежности сущности СЧЕТ является обязательным. Тогда согласно правилу 4 должны быть сгенерированы две таблицы. Примечание. Если внешний ключ представляет связь 1:М, то должны быть разрешены его дублирующие значения.

Правило 5

Если связь типа 1:М и класс принадлежности сущности на стороне М является необязательным, то необходимо построить три таблицы - по одной для каждой сущности и одну для связи. Первичный ключ сущности должен быть первичным ключом соответствующей таблицы. Таблица для связи среди своих атрибутов должна иметь ключи обеих сущностей. Представим, что на ER-диаграмме связи 1:М, изображенной на рис. 1.5, класс принадлежности сущности СЧЕТ является необязательным. Тогда согласно правилу 5 должны быть сгенерированы три таблицы. При этом осуществляется декомпозиция связи 1:М на две связи -- 1:М и 1:1. Для связи типа M:N класс принадлежности сущности не имеет значения.

Правило 6

Если связь типа M:N, то необходимо построить три таблицы - по одной для каждой сущности и одну для связи. Первичный ключ сущности должен быть первичным ключом соответствующей таблицы. Таблица для связи среди своих атрибутов должна иметь ключи обеих сущностей.ER-диаграмма связи M:N имеется на рис. 1.5. Согласно правилу 6 на основе этой ER-диаграммы должны быть сгенерированы три таблицы. При этом осуществляется декомпозиция связи M:N на две связи 1:М. В таблице КЛИЕНТ-СЧЕТ клиенту, имеющему, например, три счета будут соответствовать три строки с одним и тем же номером клиента. А счет, у которого, например, два владельца, представляется двумя строками с различными номерами клиентов, владеющими этим счетом. К ER-модели предметной области БАНК, представленной на рис. 1.5 , применимы правила 1, 4, 6. Связь МЕНЕДЖЕР - ФИЛИАЛ представляется (согласно правилу 1) одной таблицей. Связь ФИЛИАЛ - СЧЕТ представляется (согласно правилу 4) связью. Связь КЛИЕНТ - СЧЕТ представляется (согласно правилу 6) связью. Анализ состава атрибутов полученных таблиц А, В, С, D, E, F показывает, что таблица В является составной частью таблицы А, таблица Е -- составной частью таблицы С. Поэтому таблицы В, Е можно исключить из рассмотрения. Оставшиеся таблицы. А, С, D, F можно связать посредством связи первичных и внешних ключей как на рис. 1.7. В результате получим реляционную модель для ER-модели предметной области БАНК.

1.5 Нормализация таблиц

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

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

Банк	Код банка	Наименование	Адрес	Директор

Пластиковая карта	Номер карты	Банк	Пароль	Тип карты

Клиент	Номер карты	ФИО клиента	Номер счета

Счет	Номер счета	Тип счета	Остаток на карте

Рис. 1.7. Реляционная модель предметной области БАНК

банк
Код банка	Наименование банка	Адрес	Директор
123585477	Вакобанк	ул. Заречная 52	Матвеев Н.С.
123654785	Газпром банк	ул. Колхозная 16	Никитин В. С.
123654789	ВладбизнесБанс	ул. Вершинина 35	Муравьев Ш.Ш.
125463997	девон-кредит	ул. Рыбалко 20	Цветкова А.И.
125469875	Витязь	ул. Маяковского 68	Жуков П.У.
125698753	Гефест	ул. Рокоссовского 2	Носов Э.В.
125896302	Голдман Сакс ба	ул. Ким 8	Гейнц Д.Г.
128568655	дельтаКредит	ул. Мира 85	Петрова О.Ю.
159753012	Волга кредит	ул. Степная 34	Соболев Е.Ю.

Рис. 1.8

Примечание. Если таблица является объектом реляционной базы данных, то ее столбцы называются полями, а строки - записями.

2. Минимальное использование отсутствующих значений (Null-значений). В нашем примере неясно, означают ли Null- значения атрибута. Из-за неопределенности интерпретации Null-значений их использование желательно свести к минимуму.

3. Предотвращение потери информации. Минимизировать избыточность данных позволяет процесс, называемый нормализацией таблиц. Нормализацию можно было использовать для получения эффективных структур данных, созданных в результате преобразования ER-диаграмм в таблицы в предыдущем параграфе. Но чтобы пояснить этот процесс, будем исходить из описания предметной области БАНК, данного в параграфе 1.3, и предположения, что на его основе была разработана база данных, состоящая из следующих двух таблиц:

Клиент
Номер карты	ФИО клиента	Номер счета
111111111	Козлов Д.Ж.	548796210
165654146	Соловьева Т.Т.	549652135
202020202	Тарасова О.Т.	856230172

Рис.1.9

обслуживание банкомата
Кассир	Инженер	Банк
Агафонов А.Ш.	ДонсковД.Л.	Балаково-Банк
Андреева О.Д.	Цвиренко С.Ш.	Газпром банк
Вышников Н.Х.	Ушаков У.А.	Волга кредит
Галиева О.С.	Андреев О.С.	Гефест
Гришигн Т.Б.	Яшин .Ф.У.
Гуляева В.В.	Ковалев С.Б.	Приватбанк
Данкова К.Т.	Дашков Т.М.	девон-кредит
Есионова Д.Р.	Энс Б.Е.	Джей энд Ти бан
Зимин Н.О.	Авдеева М.П.	Банк24.ру
Калашников И.Б.	Егоров Д.Р.	ВладбизнесБанс

Рис.1.10

Методику нормализации таблиц разработал американский ученый А.Ф. Кодд в 1970 г. Ее суть сводится к приведению таблиц к той или иной нормальной форме. Были выделены три нормальные формы - 1НФ, 2НФ, ЗНФ. Позже стали выделять нормальную форму Бойса-Кодда (НФБК), а затем 4НФ и 5НФ. Каждая последующая нормальная форма вводит определенные ограничения на хранимые в базе данные. Реляционная база данных считается эффективной, если все ее таблицы находятся как минимум в ЗНФ. Приведение к ЗНФ осуществляется, если есть основание для этого.

Определение 1НФ

Таблица находится в 1НФ, если все ее поля содержат только простые неделимые значения.

Таблицы ОБСЛУЖИВАНИЕ БАНКОМАТА и КЛИЕНТ не удовлетворяют требованиям 1НФ. Для приведения их к 1НФ в них надо вставить новые записи следующим образом:

счет
Номер сета	Остаток на карте	Тип счета
111111111	111000	платежная
165654146	224454	кредитная
202020202	534684	дебитовая
203658962	654842	кредитная
211321212	654865415	дебитовая
213590254	536	дебитовая
213658952	658478465	кредитная
215687426	65487450	платежная
222222222	65465451	дебитовая
230230230	684846	платежная
303030300	65846451	кредитная
333333333	54151210	дебитовая
345435454	5451210	дебитовая
523566987	54654654151	платежная
542036897	548948451	дебитовая

Рис.1.11

Но полученные таблицы неэффективны, так как содержат много избы-точной информации. Необходимо их привести к 2НФ.

Определение 2НФ

Таблица находится в 2НФ, если она удовлетворяет требованиям 1НФ и неключевые поля функционально полно зависят от первичного ключа. Функциональная зависимость -- это понятие, отображающее определенную семантическую связь между полями таблицы. Пусть (X1, X2,...,XK) - множество полей, образующих первичный ключ. Не ключевое поле А функционально полно зависит от первичного ключа, если:

* оно функционально зависит от первичного ключа, т.е. каждой комбинации значений полей первичного ключа соответствует одно и только одно значение поля А, что записывается (Х1,Х 2,...,Х к ) А

* не существует функциональной зависимости А ни от какого подмножества полей первичного ключа (в противном случае А находится в частичной функциональной зависимости от первичного ключа).В таблице КЛИЕНТ не ключевые поля ФИО_К, СОЦ_П, АДР_К функционально зависят от ключа (НК, НС), что запишем НК,НС ФИО_К, СО11_П, АДР_К. Кроме того, они функционально зависят от подмножества ключа - НК, что запишем НК ФИО_К, АДР_К, СО11_П. Следовательно, не ключевые поля ФИО_К, СОЦ_П, АДР_К находятся в частичной функциональной зависимости от первичного ключа (НК, НС) и нарушаются требования 2НФ. Эти поля надо из таблицы КЛИЕНТ удалить. Полученную в результате этого таблицу назовем КЛИЕНТ-СЧЕТ, которая имеет вид КЛИЕНТ-СЧЕТ. Эта таблица удовлетворяет требованиям 2НФ. Удаленные не ключевые поля помещаются в новую таблицу совместно с подмножеством НК, от которого они зависят. И это подмножество будет первичным ключом новой таблицы КЛИЕНТ вида КЛИЕНТ. Новая таблица КЛИЕНТ также удовлетворяет требованиям 2НФ. Ее не ключевые поля функционально полно зависят от первичного ключа. Полученные таблицы 1, 2 не содержат избыточной информации, и нет основания приводить их к ЗНФ. Таблица ФИЛИАЛ удовлетворяет требованиям 2НФ, так как ее не ключевые поля НФ, АДР_Ф, НМ, ОСТ, ТИП функционально полно зависят от первично -го ключа НС НФ, АДР_Ф, НМ, ОСТ, ТИП. Но в таблице ФИЛИАЛ повторяется информация о филиале для всех счетов, обрабатываемых им. Поэтому ее надо привести к ЗНФ. Определение ЗНФ. Таблица находится в ЗНФ, если она удовлетворяет требованиям 2НФ и не содержит транзитивных зависимостей. Транзитивной зависимостью называется функциональная зависимость между не ключевыми полями. В таблице ФИЛИАЛ она наблюдается НФ АДР_Ф, НМ. Следовательно, нарушаются требования ЗНФ. Из таблицы ФИЛИАЛ надо удалить поля, участвующие в этой транзитивной зависимости, -- АДР_Ф, НМ. Получится таблица, характеризующая счет, вида СЧЕТ. Затем создается новая таблица, в которую помещаются удаленные поля и поле, от которого они зависят.

Полученные таблицы приведены к ЗНФ. В них каждая запись есть отдельное независимое утверждение. Повторяются только значения внешнего ключа НФ в таблице СЧЕТ, ЧТО неизбежно, так как одним филиалом могут обрабатываться несколько счетов. Как видим, нормализация приводит к фрагментации исходных таблиц. В нашем примере таблица КЛИЕНТ разбивается на таблицы 1, 2, а таблица ФИЛИАЛ -- на таблицы 3, 4. Осуществив связь этих таблиц посредством связи первичных и внешних ключей, получим реляционную модель данных предметной области БАНК, в которой минимизирована избыточность данных.

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

Проектирование базы данных осуществляется в три этапа:

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

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

3) физическое проектирование.

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

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

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

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

3. Создание ER-модели предметной области. Для представления сущностей и связей между ними используются ER-диаграммы. На их основе создается единый наглядный образ моделируемой предметной области - ER-модель предметной области.

4.Определение атрибутов и их документирование. Выявляются все атрибуты, описывающие сущности созданной ER-модели. Каждому атрибуту присваивается осмысленное имя, понятное пользователям. О каждом атрибуте в словарь данных помещаются следующие сведения:

* имя атрибута и его описание;

* тип и размерность значений;

* значение, принимаемое для атрибута по умолчанию (если такое имеется);

* может ли атрибут иметь Null-значения;

* является ли атрибут составным, и если это так, то из каких простых атрибутов он состоит. Например, атрибут "Ф.И.О. клиента" может состоять из простых атрибутов "Фамилия", "Имя", "Отчество", а может быть простым, содержащим единые значения, как-то "Содомский Евгений Михайлович". Если пользователь не нуждается в доступе к отдельным элементам "Ф.И.О.", то атрибут представляется как простой;

* является ли атрибут расчетным, и если это так, то как вычисляются его значения.

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

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

7.Обсуждение концептуальной модели данных с конечными пользователями. Концептуальная модель данных представляется ER-моделью с сопроводительной документацией, содержащей описание разработанной модели данных. Если будут обнаружены несоответствия предметной области, то в модель вносятся изменения до тех пор, пока пользователи не подтвердят, что предложенная им модель адекватно отображает их личные представления.

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

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

1.Выбор модели данных. Чаще всего выбирается реляционная модель данных в связи с наглядностью табличного представления данных и удобства работы с ними.

2.Определение набора таблиц исходя из ER-модели и их документирование. Для каждой сущности ER-модели создается таблица. Имя сущности - имя таблицы. Осуществляется формирование структуры таблиц на основан на изложенных в параграфе 1.4 правил. Устанавливаются связи между таблицами посредством механизма первичных и внешних ключей. Структуры таблиц и установленные связи между ними документируются.

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

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

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

* обязательные данные. Выясняется, есть ли атрибуты, которые не могут иметь Null-значений;

* ограничения для значений атрибутов. Определяются допустимые значения для атрибутов;

* целостность сущностей. Она достигается, если первичный ключ сущности не содержит Null-значений;

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

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

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

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

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

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

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

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

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

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

2. Создание базы данных



Рис.1.1 таблица «Банк»

Рис.1.2 таблица «Клиент»

Рис .1.3 таблица «менеджер»



Рис. 1.4 таблица «Обслуживание банкомата»

Рис. 1.5 таблица «Пластиковая карта»

Рис.1.6 таблица «Счет»



Рис.1.7 Запрос 1 «Номер карты - Банк»

Рис.1.8 Запрос «Банк-Кассир»



Рис.1.9 Запрос «Тип карты - ФИО клиента»

Рис.2.1 Форма «Банк»



Рис.2.2 Форма «Клиент»

Рис.2.3 Форма «Обслуживание банкомата»



Рис.3.1 Форма «Меню»

Рис.4.1 Форма «Банк»



Рис.5.1 Конструктор формы «Пластиковая карта»

Рис.6.1 Структура базы данных



Рис.6.2 Конструктор формы «Меню»

Рис. 6.3 Макрос

Рис.6.4 Конструктор запроса

SQL

1(номер карты - наименование карты)

SELECT Клиент.[Номер карты], банк.[Наименование банка]

FROM банк INNER JOIN ([пластиковая карта] INNER JOIN Клиент ON [пластиковая карта].[Номер карты] = Клиент.[Номер карты]) ON банк.[Наименование банка] = [пластиковая карта].Банк;

2(пароль - номер карты)

SELECT Клиент.[Номер карты], [пластиковая карта].Пароль

FROM Клиент INNER JOIN [пластиковая карта] ON Клиент.[Номер карты] = [пластиковая карта].[Номер карты];

3(тип карты - ФИО клиента)

SELECT [пластиковая карта].[тип карты], Клиент.[ФИО клиента]

FROM [пластиковая карта] INNER JOIN Клиент ON [пластиковая карта].[Номер карты] = Клиент.[Номер карты];

Задание: Проект БАНКОМАТЫ

Сведения об операциях выдачи наличных денег клиентам банкоматами с взиманием комиссионных вознаграждений

Рис.6.5 отчет



Список литературы

1. Анализ требований к автоматизированным информационным системам Интернет-Университет Информационных технологий. http://www.INTUIT.ru.

2. Буч Г. Объектно-ориентированное проектирование с примерами применения / Пер. с англ. / Г.Буч. - М.: Конкорд, 1992.

3. Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем. - М.: Финансы и статистика, 1998.

4. Гвоздева Т.В. Проектирование информационных систем: учебное пособие. - Ростов н/Д: Феникс, 2009.

5. IBM Rational Rose. http://www-01.ibm.com/software/rational/.

6. Паронджанов С.Д. Методология создания корпоративных ИС. Компания Аргуссофт. 96, http:///www.citforum.ru/database/ kbd96/43.shtml.

7. Проектирование информационных систем: учеб.пособие для вузов / под общей ред. К.И.Курбакова. М.: Российская экономическая академия, 2000.

8. Фоменков С.А. Лекции по курсу моделирования. http://vstuhelp.narod.ru.

9. Черемных С.В. Моделирование и анализ систем: IDEF-технологии: практикум / С.В.Черемных. - М.: Финансы и статистика, 2002.

10. Черемных С.В. Структурный анализ систем: IDEF-технологии: практикум / С.В.Черемных. - М.: Финансы и статистика, 2003.

11. Материал из Википедии -- свободной энциклопедии. http://ru.wikipedia.org/wiki/Rational_Software.

12. Форум на Исходниках.RU. http://forum.sources.ru/index.php?showtopic=8936.

13. Форум на Исходниках.RU. http://forum.sources.ru/index.php?showtopic=292553.

14. Гвоздева Т.В. Проектирование информационных систем. Ч.1. Методы структурного анализа. Планирование и управление проектами: лаб.практикум / ГОУ ВПО "Ивановский государственный энергетический университет имени В.И.Ленина". - Иваново, 2005.

Размещено на Allbest.ru