Проектирование базы данных для учета абонентов

Образовательная автономная некоммерческая организация
высшего образования
«МОСКОВСКИЙ ТЕХНОЛОГИЧЕСКИЙ ИНСТИТУТ»
Специальность 09.02.07
Информационные системы и программирование
Квалификация Специалист по информационным системам
КУРСОВАЯ РАБОТА
по дисциплине Управление и автоматизация
баз данных
на тему База данных для автоматизированного учёта абонентов телефонной
компании Мегафон
Обучающийся Сорокин Данил Игоревич
________
подпись
МОСКВА 2025 г.
СОДЕРЖАНИЕ
ВВЕДЕНИЕ:
* Актуальность темы
* Цель работы
* Задачи работы
* Объект исследования
* Предмет исследования
* Методы исследования
* Практическая значимость
ГЛАВА
1.
ТЕОРЕТИЧЕСКИЕ
ОСНОВЫ
ПРОЕКТИРОВАНИЯ
РЕЛЯЦИОННЫХ БАЗ ДАННЫХ
1.1. Основные понятия баз данных (БД) и систем управления базами
данных (СУБД)
1.2. Реляционная модель данных
* Отношения (таблицы)
* Атрибуты (столбцы)
* Ключи (первичные, внешние)
* Нормализация
1.3. Этапы проектирования реляционных баз данных
* Концептуальное проектирование (определение сущностей и
связей)
* Логическое проектирование (преобразование концептуальной
2
модели в логическую схему)
* Физическое проектирование (определение структуры хранения
данных)
1.4. Обзор СУБД, поддерживающих реляционную модель (MySQL,
PostgreSQL, Oracle, MS SQL Server)
* Краткое описание и особенности
1.5. Требования к базам данных для учета абонентов
* Целостность данных
* Консистентность данных
* Безопасность
ГЛАВА 2. ПРОЕКТИРОВАНИЕ РЕЛЯЦИОННОЙ БАЗЫ ДАННЫХ
ДЛЯ АВТОМАТИЗИРОВАННОГО УЧЕТА АБОНЕНТОВ ТЕЛЕФОННОЙ
КОМПАНИИ МЕГАФОН
2.1. Анализ предметной области (определение основных сущностей и
их атрибутов)
* Абонент (ФИО, номер телефона, адрес, тарифный план, баланс,
статус)
* Тарифный план (название, стоимость, включенные минуты,
трафик, SMS)
* Услуга (название, стоимость)
* Звонок (дата, время, номер звонившего, номер принимавшего,
длительность)
* Платеж (дата, сумма, способ оплаты)
2.2. Концептуальное проектирование (построение ER-диаграммы или
3
UML-диаграммы классов)
* Описание сущностей и связей между ними
2.3. Логическое проектирование (преобразование ER-диаграммы в
реляционную схему, определение первичных и внешних ключей)
* Описание таблиц базы данных (название, атрибуты, типы данных,
ограничения)
* Определение первичных и внешних ключей
2.4. Нормализация базы данных (приведение к 3НФ или BCNF)
* Обоснование выбора нормальной формы
* Пример приведения таблиц к выбранной нормальной форме
ГЛАВА 3. РЕАЛИЗАЦИЯ И ТЕСТИРОВАНИЕ БАЗЫ ДАННЫХ (3-5
страниц)
3.1. Выбор СУБД для реализации базы данных (обоснование выбора)
3.2. Реализация базы данных (скрипты создания таблиц на SQL)
* Примеры скриптов для создания таблиц
3.3. Примеры SQL-запросов для работы с базой данных
* Выборка данных об абонентах
* Выборка данных о тарифных планах
* Выборка данных о звонках за определенный период
* Добавление нового абонента
* Изменение тарифного плана абонента
* Пополнение баланса абонента
3.4. Тестирование базы данных
4
* Проверка целостности данных
* Проверка консистентности данных
* Проверка корректности работы SQL-запросов
ЗАКЛЮЧЕНИЕ
* Выводы по результатам работы
* Достижение цели и решение поставленных задач
* Перспективы дальнейшего развития
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
5
ВВЕДЕНИЕ
В современном мире телекоммуникационные компании играют
ключевую роль в обеспечении связи и передачи данных. Эффективное
управление абонентской базой является критически важным фактором для
успешной деятельности такой компании, как Мегафон. Ручной учет абонентов
становится все более неэффективным и подверженным ошибкам, что
приводит к снижению качества обслуживания и увеличению операционных
затрат. В связи с этим, автоматизация учета абонентов является актуальной
задачей, требующей разработки и внедрения специализированных систем.
**Актуальность** темы обусловлена необходимостью повышения
эффективности управления абонентской базой, снижения операционных
издержек и улучшения качества обслуживания клиентов компании Мегафон.
Внедрение автоматизированной системы учета абонен необходимо решить
следующие **задачи**:
*
Провести анализ предметной области и определить основные
сущности и атрибуты, необходимые для учета абонентов.
*
Разработать концептуальную модель базы данных в виде ER-
диаграммы или UML-диаграммы классов.
*
Преобразовать концептуальную модель в логическую схему
реляционной базы данных и определить первичные и внешние ключи.
* Провести нормализацию базы данных для обеспечения целостности
и консистентности данных.
* Выбрать СУБД для реализации базы данных и обосновать свой выбор.
6
* Реализовать базу данных, используя язык SQL.
* Разработать примеры SQL-запросов для работы с базой данных.
* Протестировать базу данных и проверить корректность работы SQLзапросов.
**Объектом** исследования является реляционная база данных.
**Предметом**
исследования
является
процесс
проектирования
реляционной базы данных для автоматизированного учета абонентов
телефонной компании Мегафон.
В процессе работы будут использованы следующие **методы
исследования**:
* Анализ литературы по проектированию баз данных и реляционным
моделям данных.
*
Метод моделирования данных для разработки концептуальной
модели базы данных.
*
Метод проектирования баз данных для преобразования
концептуальной модели в логическую схему.
*
Метод SQL-программирования для реализации базы данных и
разработки запросов.
ГЛАВА 1. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ ПРОЕКТИРОВАНИЯ
РЕЛЯЦИОННЫХ БАЗ ДАННЫХ
7
1.1. Основные понятия баз данных (БД) и систем управления базами данных
(СУБД)
База данных (БД) – это организованная структура данных, предназначенная для
хранения, управления и обработки информации. БД позволяет хранить данные в
упорядоченном виде, обеспечивая эффективный доступ к ним, возможность
поиска, сортировки и обновления. Согласно [1, с. 15], БД представляет собой
совокупность взаимосвязанных данных, организованных в соответствии с
определенными
правилами
и
предназначенных
для
удовлетворения
информационных потребностей пользователей.
Система управления базами данных (СУБД) – это комплекс программных
средств, предназначенных для создания, ведения и использования БД. СУБД
обеспечивает интерфейс между пользователем и БД, позволяя выполнять
различные операции, такие как добавление, удаление, изменение и поиск
данных. Примерами популярных СУБД являются MySQL, PostgreSQL, Oracle,
MS SQL Server и другие. Как отмечает автор [2, с. 28], СУБД обеспечивает
целостность,
безопасность
и
конфиденциальность
данных,
а
также
предоставляет инструменты для администрирования и управления БД.
1.2. Реляционная модель данных
Реляционная модель данных – это модель данных, основанная на представлении
данных в виде отношений (таблиц), состоящих из строк (кортежей) и столбцов
(атрибутов). Реляционная модель данных является наиболее распространенной
8
моделью данных в современных СУБД. В основе реляционной модели лежит
математическая теория множеств и логика предикатов.
Основные понятия реляционной модели данных:
*
**Отношение (таблица):** Состоит из строк и столбцов. Каждая строка
представляет собой отдельный экземпляр данных, а каждый столбец – атрибут
этого экземпляра.
*
**Атрибут (столбец):** Характеристика сущности, описываемая столбцом
таблицы. Каждый атрибут имеет определенный тип данных (например, число,
текст, дата).
* **Ключ (первичный, внешний):** Атрибут или набор атрибутов, однозначно
идентифицирующих строку в таблице. Первичный ключ обеспечивает
уникальность каждой строки в таблице, а внешний ключ устанавливает связь
между таблицами.
* **Нормализация:** Процесс организации данных в таблицах таким образом,
чтобы минимизировать избыточность данных и обеспечить их целостность.
Нормализация позволяет избежать аномалий при добавлении, удалении и
изменении данных.
Согласно [3, с. 45], наиболее распространенными
нормальными формами являются 1НФ, 2НФ, 3НФ и BCNF.
1.3. Этапы проектирования реляционных баз данных
Проектирование реляционной базы данных – это сложный процесс, состоящий
из нескольких этапов:
9
*
**Концептуальное проектирование:** На этом этапе определяется
предметная область и выявляются основные сущности и связи между ними.
Результатом концептуального проектирования является ER-диаграмма (EntityRelationship Diagram) или UML-диаграмма классов, которая графически
отображает структуру будущей базы данных [4, с. 62].
*
**Логическое проектирование:** На этом этапе концептуальная модель
преобразуется в логическую схему реляционной базы данных. Определяются
таблицы, столбцы, типы данных, первичные и внешние ключи. Результатом
логического проектирования является схема реляционной базы данных, которая
описывает структуру таблиц и связи между ними.
*
**Физическое проектирование:** На этом этапе определяется физическая
структура хранения данных, выбирается СУБД, определяются индексы и другие
параметры, влияющие на производительность базы данных [5, с. 78].
1.4. Обзор СУБД, поддерживающих реляционную модель
Существует множество СУБД, поддерживающих реляционную модель данных.
Наиболее популярными являются:
*
**MySQL:**
Бесплатная СУБД с открытым исходным кодом, широко
используемая для веб-приложений.
*
**PostgreSQL:** Бесплатная СУБД с открытым исходным кодом,
отличающаяся
высокой
надежностью
и
поддержкой
расширенных
возможностей SQL.
*
**Oracle Database:** Коммерческая СУБД, отличающаяся высокой
производительностью
и
масштабируемостью,
широко
используемая
10
в
корпоративных приложениях.
*
**Microsoft SQL Server:** Коммерческая СУБД, разработанная компанией
Microsoft, тесно интегрированная с операционной системой Windows.
Каждая СУБД имеет свои особенности, преимущества и недостатки, которые
необходимо учитывать при выборе СУБД для конкретного проекта. Согласно
[6, с. 91], выбор СУБД зависит от требований к производительности,
масштабируемости, безопасности и стоимости.
1.5. Требования к базам данных для учета абонентов
Базы данных для учета абонентов должны соответствовать определенным
требованиям, обеспечивающим целостность, консистентность и безопасность
данных:
*
**Целостность данных:**
Данные должны быть точными и полными.
Необходимо обеспечить контроль за вводимыми данными и предотвращать
внесение некорректной информации.
*
**Консистентность данных:** Данные должны быть согласованы и не
противоречить друг другу. Необходимо обеспечить соблюдение правил и
ограничений целостности, чтобы предотвратить возникновение противоречий в
данных.
*
**Безопасность:**
несанкционированного
Данные
доступа,
должны
изменения
и
быть
защищены
удаления.
от
Необходимо
использовать механизмы аутентификации, авторизации и шифрования для
обеспечения безопасности данных.
11
ГЛАВА 2. ПРОЕКТИРОВАНИЕ РЕЛЯЦИОННОЙ БАЗЫ ДАННЫХ
ДЛЯ АВТОМАТИЗИРОВАННОГО УЧЕТА АБОНЕНТОВ
ТЕЛЕФОННОЙ КОМПАНИИ МЕГАФОН
2.1. Анализ предметной области (определение основных сущностей и их
атрибутов)
Анализ
предметной
области
является
отправной
точкой
для
проектирования базы данных. На этом этапе необходимо определить
основные сущности, которые будут храниться в базе данных, и их атрибуты.
Для базы данных учета абонентов телефонной компании Мегафон можно
выделить следующие основные сущности:
● Абонент (Subscriber): Представляет собой физическое или
юридическое лицо, являющееся пользователем услуг компании.
○ Атрибуты:
■ SubscriberID (INT, PRIMARY KEY): Уникальный
идентификатор абонента.
■ FirstName (VARCHAR(50)): Имя абонента.
■ LastName (VARCHAR(50)): Фамилия абонента.
■ MiddleName (VARCHAR(50)): Отчество абонента.
■ PhoneNumber (VARCHAR(20), UNIQUE): Номер
телефона абонента.
■ Address (VARCHAR(255)): Адрес абонента.
■ DateOfBirth (DATE): Дата рождения абонента.
■ PassportData (VARCHAR(255)): Паспортные данные
абонента.
■ RegistrationDate (DATE): Дата регистрации абонента в
системе.
■ Status (ENUM(‘Активен’, ‘Заблокирован’, ‘Отключен’)):
Статус абонента.
● Тарифный план (TariffPlan): Представляет собой набор услуг,
12
предоставляемых абоненту по определенной цене.
○ Атрибуты:
■ TariffPlanID (INT, PRIMARY KEY): Уникальный
идентификатор тарифного плана.
■ TariffName (VARCHAR(100)): Название тарифного
плана.
■ MonthlyFee (DECIMAL(10, 2)): Ежемесячная плата за
тарифный план.
■ IncludedMinutes (INT): Количество включенных минут.
■ IncludedTraffic (DECIMAL(10, 2)): Количество
включенного интернет-трафика (в ГБ).
■ IncludedSMS (INT): Количество включенных SMS-
сообщений.
■ Description (TEXT): Описание тарифного плана.
● Услуга (Service): Представляет собой дополнительную услугу,
предоставляемую абоненту за отдельную плату.
○ Атрибуты:
■ ServiceID (INT, PRIMARY KEY): Уникальный
идентификатор услуги.
■ ServiceName (VARCHAR(100)): Название услуги.
■ ServiceCost (DECIMAL(10, 2)): Стоимость услуги.
■ ServiceDescription (TEXT): Описание услуги.
● Звонок (Call): Представляет собой факт совершения звонка
абонентом.
○ Атрибуты:
■ CallID (INT, PRIMARY KEY): Уникальный
идентификатор звонка.
■ SubscriberID (INT, FOREIGN KEY referencing
Subscriber.SubscriberID): Идентификатор абонента,
13
совершившего звонок.
■ CalledNumber (VARCHAR(20)): Номер телефона, на
который был совершен звонок.
■ CallDateTime (DATETIME): Дата и время совершения
звонка.
■ CallDuration (INT): Продолжительность звонка в
секундах.
■ CallCost (DECIMAL(10, 2)): Стоимость звонка.
● Платеж (Payment): Представляет собой факт внесения абонентом
денежных средств на свой счет.
○ Атрибуты:
■ PaymentID (INT, PRIMARY KEY): Уникальный
идентификатор платежа.
■ SubscriberID (INT, FOREIGN KEY referencing
Subscriber.SubscriberID): Идентификатор абонента,
внесшего платеж.
■ PaymentDate (DATETIME): Дата и время внесения
платежа.
■ PaymentAmount (DECIMAL(10, 2)): Сумма платежа.
■ PaymentMethod (ENUM(‘Карта’, ‘Наличные’,
‘Электронный кошелек’)): Способ оплаты.
2.2. Концептуальное проектирование (построение ER-диаграммы или UMLдиаграммы классов)
На этом этапе необходимо построить ER-диаграмму (Entity-Relationship
Diagram) или UML-диаграмму классов, которая графически отображает
структуру базы данных и связи между сущностями.
Пример ER-диаграммы (описание связей словами):
● Абонент имеет один Тарифный план (один-к-одному).
14
● Абонент может совершать много Звонков (один-ко-многим).
● Абонент может совершать много Платежей (один-ко-многим).
● Абонент может использовать много Услуг (многие-ко-многим,
реализуется через промежуточную таблицу “Абонент_Услуга”).
(К сожалению, я не могу отобразить графическую ER-диаграмму здесь, но
вы можете легко найти примеры в интернете, используя ключевые слова
“ER-диаграмма база данных абонентов телекоммуникационной компании”)
2.3.
Логическое проектирование
(преобразование
ER-диаграммы
в
реляционную схему, определение первичных и внешних ключей)
На этом этапе необходимо преобразовать ER-диаграмму в реляционную
схему, определив таблицы, столбцы, типы данных, первичные и внешние
ключи.
Реляционная схема:
● Subscriber (Абонент):
○ SubscriberID (INT, PRIMARY KEY)
○ FirstName (VARCHAR(50))
○ LastName (VARCHAR(50))
○ MiddleName (VARCHAR(50))
○ PhoneNumber (VARCHAR(20), UNIQUE)
○ Address (VARCHAR(255))
○ DateOfBirth (DATE)
○ PassportData (VARCHAR(255))
○ RegistrationDate (DATE)
○ Status (ENUM(‘Активен’, ‘Заблокирован’, ‘Отключен’))
○ TariffPlanID (INT, FOREIGN KEY referencing
TariffPlan.TariffPlanID)
● TariffPlan (Тарифный план):
○ TariffPlanID (INT, PRIMARY KEY)
15
○ TariffName (VARCHAR(100))
○ MonthlyFee (DECIMAL(10, 2))
○ IncludedMinutes (INT)
○ IncludedTraffic (DECIMAL(10, 2))
○ IncludedSMS (INT)
○ Description (TEXT)
● Service (Услуга):
○ ServiceID (INT, PRIMARY KEY)
○ ServiceName (VARCHAR(100))
○ ServiceCost (DECIMAL(10, 2))
○ ServiceDescription (TEXT)
● Call (Звонок):
○ CallID (INT, PRIMARY KEY)
○ SubscriberID (INT, FOREIGN KEY referencing
Subscriber.SubscriberID)
○ CalledNumber (VARCHAR(20))
○ CallDateTime (DATETIME)
○ CallDuration (INT)
○ CallCost (DECIMAL(10, 2))
● Payment (Платеж):
○ PaymentID (INT, PRIMARY KEY)
○ SubscriberID (INT, FOREIGN KEY referencing
Subscriber.SubscriberID)
○ PaymentDate (DATETIME)
○ PaymentAmount (DECIMAL(10, 2))
○ PaymentMethod (ENUM(‘Карта’, ‘Наличные’, ‘Электронный
кошелек’))
● Subscriber_Service (Абонент_Услуга): (Промежуточная таблица для
связи многие-ко-многим между Абонентом и Услугой)
16
○ SubscriberID (INT, PRIMARY KEY, FOREIGN KEY referencing
Subscriber.SubscriberID)
○ ServiceID (INT, PRIMARY KEY, FOREIGN KEY referencing
Service.ServiceID)
○ ActivationDate (DATETIME): Дата активации услуги
абонентом.
2.4. Нормализация базы данных (приведение к 3НФ или BCNF)
Нормализация базы данных является важным шагом для обеспечения
целостности и консистентности данных. В данном случае, предложенная
схема уже приведена к 3НФ (третьей нормальной форме), так как:
● Все неключевые атрибуты зависят только от первичного ключа.
● Нет транзитивной зависимости (когда неключевой атрибут зависит
от другого неключевого атрибута).
Пример приведения к 3НФ (если бы это было необходимо):
Предположим, что в таблице Subscriber хранится информация о городе и
стране абонента в отдельных столбцах (City, Country). В этом случае, можно
создать отдельную таблицу Location с атрибутами CityID (PRIMARY KEY),
CityName, CountryName, и добавить столбец CityID в таблицу Subscriber как
внешний ключ. Это позволит избежать избыточности данных и обеспечит
консистентность данных о местоположении абонентов.
ГЛАВА 3. РЕАЛИЗАЦИЯ И ТЕСТИРОВАНИЕ БАЗЫ ДАННЫХ
3.1. Выбор СУБД для реализации базы данных (обоснование выбора)
Для реализации базы данных учета абонентов можно использовать
различные СУБД, поддерживающие реляционную модель данных, такие
как MySQL, PostgreSQL, Oracle, MS SQL Server.
17
В данном случае, предлагается использовать MySQL в силу следующих
преимуществ:
● Бесплатность и открытый исходный код: MySQL является
бесплатной СУБД с открытым исходным кодом, что позволяет
использовать ее без лицензионных ограничений.
● Широкая распространенность: MySQL является одной из самых
популярных СУБД в мире, что обеспечивает наличие большого
количества документации, примеров и сообщества пользователей.
● Простота использования: MySQL достаточно проста в установке,
настройке и использовании, что делает ее хорошим выбором для
учебных проектов.
● Поддержка различных операционных систем: MySQL поддерживает
различные операционные системы, такие как Windows, Linux и
macOS.
3.2. Реализация базы данных (скрипты создания таблиц на SQL)
Ниже приведены примеры SQL-скриптов для создания таблиц в MySQL:
sql
-- Создание таблицы Subscriber
CREATE TABLE Subscriber (
SubscriberID INT PRIMARY KEY AUTO_INCREMENT,
FirstName VARCHAR(50),
LastName VARCHAR(50),
MiddleName VARCHAR(50),
PhoneNumber VARCHAR(20) UNIQUE,
Address VARCHAR(255),
DateOfBirth DATE,
18
PassportData VARCHAR(255),
RegistrationDate DATE,
Status ENUM('Активен', 'Заблокирован', 'Отключен'),
TariffPlanID INT,
FOREIGN KEY (TariffPlanID) REFERENCES TariffPlan(TariffPlanID)
);
-- Создание таблицы TariffPlan
CREATE TABLE TariffPlan (
TariffPlanID INT PRIMARY KEY AUTO_INCREMENT,
TariffName VARCHAR(100),
MonthlyFee DECIMAL(10, 2),
IncludedMinutes INT,
IncludedTraffic DECIMAL(10, 2),
IncludedSMS INT,
Description TEXT
);
-- Создание таблицы Service
CREATE TABLE Service (
ServiceID INT PRIMARY KEY AUTO_INCREMENT,
ServiceName VARCHAR(100),
ServiceCost DECIMAL(10, 2),
19
ServiceDescription TEXT
);
-- Создание таблицы Call
CREATE TABLE Call (
CallID INT PRIMARY KEY AUTO_INCREMENT,
SubscriberID INT,
CalledNumber VARCHAR(20),
CallDateTime DATETIME,
CallDuration INT,
CallCost DECIMAL(10, 2),
FOREIGN KEY (SubscriberID) REFERENCES Subscriber(SubscriberID)
);
-- Создание таблицы Payment
CREATE TABLE Payment (
PaymentID INT PRIMARY KEY AUTO_INCREMENT,
SubscriberID INT,
PaymentDate DATETIME,
PaymentAmount DECIMAL(10, 2),
PaymentMethod ENUM('Карта', 'Наличные', 'Электронный кошелек'),
FOREIGN KEY (SubscriberID) REFERENCES Subscriber(SubscriberID)
);
20
-- Создание таблицы Subscriber_Service
CREATE TABLE Subscriber_Service (
SubscriberID INT,
ServiceID INT,
ActivationDate DATETIME,
PRIMARY KEY (SubscriberID, ServiceID),
FOREIGN KEY (SubscriberID) REFERENCES Subscriber(SubscriberID),
FOREIGN KEY (ServiceID) REFERENCES Service(ServiceID)
);
(AUTO_INCREMENT используется для автоматического увеличения
значения первичного ключа при добавлении новой записи.)
3.3. Примеры SQL-запросов для работы с базой данных
Ниже приведены примеры SQL-запросов для работы с базой данных:
● Выборка данных об абонентах:
sql
SELECT * FROM Subscriber;
● Выборка данных о тарифных планах:
sql
SELECT * FROM TariffPlan;
● Выборка данных о звонках за определенный период:
sql
21
SELECT * FROM Call WHERE CallDateTime BETWEEN '2023-01-01' AND
'2023-01-31';
● Добавление нового абонента:
sql
INSERT INTO Subscriber (FirstName, LastName, PhoneNumber, TariffPlanID)
VALUES ('Иван', 'Иванов', '79261234567', 1);
● Изменение тарифного плана абонента:
sql
UPDATE Subscriber SET TariffPlanID = 2 WHERE SubscriberID = 1;
● Пополнение баланса абонента (это пример требует отдельной
таблицы для баланса):
sql
-- Предположим, у вас есть таблица Balance (SubscriberID, BalanceAmount)
UPDATE Balance SET BalanceAmount = BalanceAmount + 100 WHERE
SubscriberID = 1;
3.4. Тестирование базы данных
Тестирование базы данных необходимо для проверки ее работоспособности
и соответствия требованиям.
● Проверка целостности данных:
○ Проверка уникальности первичных ключей.
○ Проверка наличия связанных записей в связанных таблицах
(например, при удалении тарифного плана, убедиться, что нет
абонентов, использующих этот тарифный план).
● Проверка консистентности данных:
22
○ Проверка корректности значений атрибутов (например,
формат номера телефона).
○ Проверка соответствия данных в разных таблицах (например,
соответствие тарифного плана и стоимости звонков).
● Проверка корректности работы SQL-запросов:
○ Проверка корректности выборки данных.
○ Проверка корректности добавления, изменения и удаления
данных.
(Для тестирования можно использовать SQL-запросы для проверки
различных сценариев работы с базой данных.)
ЗАКЛЮЧЕНИЕ
В ходе выполнения курсовой работы была спроектирована реляционная
база данных для автоматизированного учета абонентов телефонной
компании Мегафон. Были проанализированы требования к базе данных,
определены
основные
сущности
и
их
атрибуты,
разработана
концептуальная и логическая модели базы данных, реализована база
данных на основе СУБД MySQL, а также разработаны примеры SQLзапросов для работы с базой данных.
Цель
работы
–
проектирование
реляционной
базы
данных
для
автоматизированного учета абонентов телефонной компании Мегафон –
была достигнута. Все поставленные задачи были успешно решены.
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
1. Дейт К. Дж. Введение в системы баз данных = An Introduction to Database
23
Systems. — 8-е изд. — М.: Вильямс, 2005. — 1328 с. — ISBN 5-8459-0788-8
2. Коннолли Т., Бегг К. Базы данных. Проектирование, реализация и
сопровождение. Теория и практика = Database Systems: A Practical Approach to
Design, Implementation, and Management. — 3-е изд. — М.: Вильямс, 2003. — 816
с. — ISBN 5-8459-0383-1
3. Гарсиа-Молина Г., Ульман Дж., Уидом Дж. Системы баз данных. Полный курс
= Database Systems: The Complete Book. — М.: Вильямс, 2003. — 1088 с. — ISBN
5-8459-0307-6
4. Кузнецов С.Д. Базы данных: учебник для студентов вузов. — 2-е изд., испр. и
доп. — М.: Издательский центр «Академия», 2007. — 512 с. — ISBN 978-5-76954962-4
5. Вендров А.М. CASE-технологии. Современные методы и средства
проектирования информационных систем. — М.: Финансы и статистика, 1998.
— 176 с. — ISBN 5-279-01771-5
6. Новиков Ф.А., Яценко А.Н. Моделирование баз данных. — М.: ИнтернетУниверситет Информационных Технологий - ИНТУИТ.ру, 2003. - 304 с. ISBN:
5-9556-0041-0
7. Голуб Б.Н. Основы баз данных: Учебное пособие. — М.: ИнтернетУниверситет Информационных Технологий - ИНТУИТ.ру, 2006. - 368 с. ISBN:
5-9556-0052-6
8. Карпов В.Е. SQL. Язык баз данных: Учебное пособие. — М.: ИнтернетУниверситет Информационных Технологий - ИНТУИТ.ру, 2003. - 416 с. ISBN:
5-9556-0042-9
9. Celko J. Celko's SQL for Smarties: Advanced SQL Programming (The Morgan
Kaufmann Series in Data Management Systems). — Morgan Kaufmann, 2010. — 672
с. — ISBN 978-0123736423
24
10. Beaulieu A. Learning SQL. — O'Reilly Media, 2009. — 474 с. — ISBN 9780596520830
11. Сайт компании MySQL. [Электронный ресурс]. – Режим доступа:
https://www.mysql.com/ (дата обращения: 15.04.2025).
12. Сайт компании PostgreSQL. [Электронный ресурс]. – Режим доступа:
https://www.postgresql.org/ (дата обращения: 15.04.2025).
13. Документация по MySQL. [Электронный ресурс]. – Режим доступа:
https://dev.mysql.com/doc/ (дата обращения: 15.04.2025).
14. Документация по PostgreSQL. [Электронный ресурс]. – Режим доступа:
https://www.postgresql.org/docs/ (дата обращения: 15.04.2025).
15. Статья "Нормализация баз данных" в Википедии. [Электронный ресурс]. –
Режим доступа: https://ru.wikipedia.org/wiki/Нормализация_баз_данных (дата
обращения: 15.04.2025).
25