DATA NORMALIZATION This is a technique of splitting a complex table in to simple meaningful tables. In here arrange tables, rows and relationships between tables in order to avoid data redundancy ( අතිරික්තතාව ) and to attain data integrity ( සම්පූර්ණත්වය ).Goal, 01. To avid data redundancy (data duplicated). 02. To attain data integrity - Data goes to inconsistence state ( ස්ථිර නෑ , අදාළ නෑ ) . 03. To put data in to correct table. 04. To avoid CRUD anomalies ( අක්රමිකතාව ). Duplicate වෙන data නවත්වන්න ඕනේ , අදාළ නැති data store වීම නවත්වන්න ඕනේ.නියමිත table වලට පමණක් නියමිට data යවන්න ඕනේ සහ DB එක සමග කරන CRUD operation වලදී අක්රමිකතා ඇති වෙන්න බෑ (අනවශ්ය data delete වීම , අනවශ්ය data add වීම ,data search කරගන්න බැරිවීම වගේ ඒවා) Partial dependency It is the dependency where non key attributes are functionally depends on any part of composite key. Full dependency It is the dependency where non ke...
Why you see it in IntelliJ but not in your project folder IntelliJ shows all dependencies under External Libraries, but they are not stored directly inside your project directory. Instead, they are downloaded and cached by your build tool (like Gradle or Maven) in a global location on your system. ~ /.gradle/ caches/modules- 2 /files- 2.1 / ~ / .m2 / repository/ You have a Maven project that uses a:1.2 → it downloads the JAR to ~/.m2/repository. Now, in a Gradle project, you also want to use a:1.2 What actually happens: Gradle does not use Maven’s .m2/repository directly. Instead: Gradle will check its own cache: ~/.gradle/caches/modules-2/files-2.1/ If a:1.2 is not found in Gradle's cache, it will: Download a:1.2 from the remote repository (e.g., Maven Central) again. Store it in the Gradle cache, not reuse from .m2. Why this happens: Gradle and Maven use different caching strategies and metadata formats, so they maintain separate repositories. BUT: You can configure Gradle to l...
How HTTPS works: Phase 1: TLS Handshake (Secure Channel Setup) Phase 2: HTTPS Communication (Encrypted Data Transfer) Phase 1: TLS Handshake (Secure Channel Setup) Step 1: Client Hello The browser (client) sends an HTTPS request to the server. It includes: A random number (`client_random`) A list of supported cipher suites (e.g., ECDHE-RSA, ECDHE-ECDSA) TLS version info Step 2: Server Hello The server responds with: Another random number (`server_random`) A selected cipher suite (e.g., ECDHE-RSA, ECDHE-ECDSA) Its digital certificate (contains public key and domain info) Step 3: Certificate Validation (Browser Side) The browser verifies the server certificate: Is it issued by a trusted Certificate Authority (CA)? Is it not expired? Is the domain name correct? If valid → continue. If not → browser shows a "connec...
Comments
Post a Comment